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Abstract 

Without adding any primitives to the language, we define a concurrency monad trans¬ 
former in Haskell. This allows us to add a limited form of concurrency to any existing 
monad. The atomic actions of the new monad are lifted actions of the underlying monad. 
Some extra operations, such as fork, to initiate new processes, are provided. We discuss 
the implementation, and use some examples to illustrate the usefulness of this construc- 


1 Introduction 

The concept of a monad (Wadler, 1995) is nowadays heavily used in modern func¬ 
tional programming languages. Monads are used to model some form of computa¬ 
tion, such as non-determinism or a stateful calculation. Not only does this solve 
many of the traditional problems in functional programming, such as I/O and mu¬ 
table state, but it also offers a general framework that abstracts over many kinds 
of computation. 

It is known how to use monads to model concurrency. To do this, one usually 
constructs an imperative monad, with operations that resemble the Unix fork 
(Jones & Hudak, 1993). For reasons of efficiency and control, Concurrent Haskell 
(Peyton Jones et al, 1996) even provides primitive operations, which are defined 
outside the language. 

This paper presents a way to model concurrency, generalising over arbitrary mon¬ 
ads. The idea is to have atomic actions in some monad that can be lifted into a 
concurrent setting. We explore this idea within the language; we will not add any 
primitives. 


2 Monads 

To express the properties of monads in Haskell, we will use the following type class 
definition. The bind operator of the monad is denoted by (*), and the unit operator 

by return. 
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class Monad m where 

(*) :: m a (a m /?) -k m /? 


Furthermore, throughout this paper we will use the so-called do-notation as syntac¬ 
tic sugar for monadic expressions. The following example illustrates a traditional 
monadic expression on the left, and the same, written in do-notation, on the right. 


expr i Xx. 

expr 3 * A y. 

return expr4 


5 expr 2 
; y <- expr3 
; return expr. 


As an example, we present a monad with output, called the writer monad. This 
monad has an extra operator called write. It takes a string as argument, which 
becomes output in a side effect of the monad. The bind operator (■*•) of the monad 
has to take care of combining the output of two computations. 

A monad having this operator is an instance of the following class. 


class Monad m => Writer m where 
write :: String —> m () 

A typical implementation of such a monad is a pair containing the result of the 
computation, together with the output produced during that computation. 


type W a = (a, String) 

instance Monad W where 

(a, s) k k = let ( b , s') = k a in ( b , s-H-s') 
return x = (x, “”) 

instance Writer W where 
write s = ((), s) 

Note how the bind operator concatenates the output of the two subactions. 

Most monads come equipped with a run function. This function executes a com¬ 
putation, taking the values inside one level downwards. The monad W has such a 
run function, we call it output, which returns the output of a computation in W. 

output :: W a —> String 

output (a, s) = s 
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2.1 Monad Transformers 

Sometimes, a monad is parametrised over another monad. This is mostly done to 
add more functionality to an existing monad. In this case we speak of a monad 
transformer (Liang et al, 1995). An example is the exception monad transformer; 
it adds a way to escape a monadic computation with an error message. In general, 
operations that work on one specific monad can be lifted into the new, extended 
monad. 

Again, we can express this by using a type class. 

class MonadTrans r where 

lift :: Monad m =y m a —>■ (r m) a 

A type constructor r forms a monad transformer if there is an operation lift that 
transforms any action in a monad m into an action in a monad r m. 

In this paper we will discuss a monad transformer called C . It has the interesting 
property that any monadic action that is lifted into the new monad will be con¬ 
sidered an atomic action in a concurrent setting. Also some extra operations are 
provided for this monad, for example fork, which deals with process initiation. 


3 Concurrency 

How are we going to model concurrency? Since we are not allowed to add primi¬ 
tives to the language, we are going to simulate concurrent processes by interleaving 
them. Interleaving implements concurrency by running the first part of one process, 
suspending it, and then allowing another process to run. 


3.1 Continuations 

To suspend a process, we need to grab its future and stick it away for later use. 
Continuations are an excellent way of doing this. We can change a function into 
continuation passing style by adding an extra parameter, the continuation. Instead 
of producing the result directly, the function will now apply the continuation to 
the result. We can view the continuation as the future of the computation, as it 
specifies what to do with the result of the function. 

Given a computation type Action , a function that uses a continuation with result 
type a has the following type. 

type C a = (a —> Action) —> Action 

The type Action contains the actual computation. Since, in our case, we want 
to parametrise this over an arbitrary monad, we want Action (and also C) to be 
dependent on a monad m. 


m a = (a —> Action m) —>■ Action m 


type C 




Koen Claessen 


C is the concurrency monad transformer we use in this paper. That means that 
C m is a monad, for every monad m. 

instance Monad m =y Monad (C m) where 
/ * * = Xc.f (Aa. k a c) 

return x = Ac. c x 

Sequencing of continuations is done by creating a new continuation for the left 
computation that contains the right computation. The unit operator just passes its 
argument to the continuation. 


3.2 Actions 

The type Action m specifies the actual actions we can do in the new monad. What 
does this type look like? For reasons of simplicity, flexibility, and expressiveness 
(Scholz, 1995), we implement it as a datatype that describes the different actions 
we provide in the monad. 

First of all, we need atoms, which are computations in the monad m. We are inside 
a continuation, so we want these atomic computations to return a new action. Also, 
we need a constructor for creating new processes. Lastly, we provide a constructor 
that does not have a continuation; we will use it to end a process. We also call this 
the empty process. 


data Action m 

= Atom (m (Action m)) 

| Fork (Action m) (Action m) 

| Stop 

To express the connection between an expression of type C m a and an expression 
of type Action m, we define a function action that transforms one into the other. 
It finishes the computation by giving it the Stop continuation. 

action :: Monad m=>C m a —>■ Action m 
action m = m (A a. Stop) 

To make the constructors of the datatype Action easily accessible, we can define 
functions that correspond to them. They will create an action in the monad C m. 

The first function is the function atom, which turns an arbitrary computation in 
the monad m into an atomic action in C m. It runs the atomic computation and 
monadically returns a new action, using the continuation.^ 

atom :: Monad m =y m a — > C m a 

atom m = Ac. Atom (do a m ; return (c a)) 


This is actually the monadic map, but because Functor is not a superclass of Monad 
Haskell we cannot use map. 
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In addition, we have a function that uses the Stop constructor, called stop . It 
discards any continuation, thus ending a computation. 

stop :: Monad m => C m a 
stop = Ac. Stop 

To access Fork, we define two operations. The first, called par, combines two 
computations into one by forking them both, and passing the continuation to both 
parts. The second, fork, resembles the more traditional imperative fork. It forks 
its argument after turning it into an action, and continues by passing () to the 
continuation. 


par :: Monad ra => C m a —» C m a —» C m a 

par mi m2 = Ac. Fork (m 1 c) (m2 c) 

fork :: Monad ra => C m a —» C m () 

fork m = Ac. Fork (action m ) (c ()) 

The type constructor C is indeed a monad transformer. Its lifting function is the 
function atom; every lifted action becomes an atomic action in the concurrent 
setting. 


instance MonadTrans C where 
lift = atom 

We have now defined ways to construct actions of type C m a, but we still can not 
do anything with them. How do we model concurrently running actions? How do 
we interpret them? 


3.3 Semantics 

At any moment, the status of the computation is going to be modelled by a list 
of (concurrently running) actions. We will use a scheduling technique called round- 
robin to interleave the processes. The concept is easy: if there is an empty list of 
processes, we are done. Otherwise, we take a process, run its first part, take the 
continuation, and put that at the back of the list. We keep doing this recursively 
until the list is empty. 

We implement this idea in the function round. 

round :: Monad m =y [Action m] —> m () 
round [] = return () 

round (a : as) = case a of 

Atom a m —>■ do a' a m ; round (as -H- [a']) 

Fork cq a 2 -t round (as -H- [ai,a 2 ]) 

Stop — y round as 
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An Atom monadically executes its argument, and puts the resulting process at the 
back of the process list. Fork creates two new processes, and Stop discards its 
process. 

As for any monad, we need a run function for C m as well. It just transforms its 
argument into an action, creates a singleton process list, and applies the round-robin 
function to it. 


run :: Monad m=^C m a ->■ m () 
run m = round [action m] 

As we can see, the type a disappears in the result type. This means that we lose 
the result of the original computation. This seems very odd, but often (and in the 
cases of the examples in this paper) we are only interested in the side effects of a 
computation. It is possible to generalise the type of run , but that goes beyond the 
scope of this paper. 


4 Examples 

We will present two examples of monads that can be lifted into the new concurrent 
world. 


4-1 Concurrent Output 

Recall the writer monad example from Sect. 2. We can try lifting this monad into 
the concurrent world. To do this, we want to say that every instance of a writer 
monad can be lifted into a concurrent writer monad. + 

instance Writer m =y Writer (C m) where 
write s = lift (write s) 

The function lift here is the atom of the monad transformer C. Every write 
action, after lifting, becomes an atomic action. This means that no computation 
will produce output while another write is writing. 

Before we present an example, we first define an auxilary function loop. This 
function works in any writer monad. It takes one argument, a string, and writes it 
repeatedly to the output. 

loop :: Writer m =y String —> m () 
loop s = do write s ; loop s 

We use this function to define a computation in C'm a that creates two processes 
that are constantly writing. One process writes the string “fish”, the other writes 


Actually, we want to say this for all monad transformers at once, but Haskell does not 
currently allow us to express this. 
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example :: Writer m =>• C m () 
example = do write “start!” 

; fork (loop “fish”) 

The result of the expression output (run example) looks like the following string. 

“start!fishcatfishcatfishcatfishcatfishcatfishca . . .” 

Because we defined write as an atomic action, the writing of one “fish” and one 
“cat” cannot interfere. If we want finer grained behaviour, we can split one write 
action into several write actions, e.g. the separate characters of a string. A simple 
way of doing this is to change the lifting of write . 

instance Writer m => Writer (C m) where 
write [] = return () 

write (c : s) = do lift (write [c]) ; write s 

The lifting is now done character-by-character. The result of the expression output 
(run example) now looks like this. 

“start!fciasthcfaitschafticsahtfciasthcfaitscha . . .” 


f.2 Merging of Infinite Lists 

A well known problem, called the merging of infinite lists, is as follows. Suppose 
we have an infinite list of infinite lists, and want to collapse this list into one big 
infinite list. The property we want to hold is that every element in any of the original 
lists is reachable within a finite number of steps in the new list. This technique is 
for example used to prove that the set Q of rationals has a countable number of 
elements. 

Using the writer monad with the new lifting, we can solve this problem for an 
infinite list of infinite strings. The idea is that, for each string, we create a process 
that writes the string. If we fork this infinite number of processes, and run the 
resulting computation, the output will be the desired infinite string. 

We will take a step back in order to present a piece of useful theory. There are 
monads that have a so-called monoidal structure on them. That means that there 
is an operator, denoted by (-H-), that combines two computations of the same type 
into one, and that there is an identity element for this operation, called zero . In 
Haskell, we can say: 


class Monad m =y Monoidal m where 

(-H-) :: ma^ma^ma 


zero 
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The function concat, with type Monoidal m => [m a\ —>■ a, uses (-H-) and zero 
to concatenate a (possibly inhnite) list of such computations together. 

The reason we are looking at this is that C m admits a monoidal structure; the 
parallel composition par represents the (-H-), and the process stop represents its 
identity element zero . 

instance Monad m =y Monoidal (C m) where 
(-H-) = par 

zero = stop 

This means we can use concat to transform an inhnite list of processes into a 
process that concurrently runs these computations. To merge an inhnite list of 
inhnite strings, we transform every string into a writing process, fork them with 
concat, and extract the output. 

merge :: [String] —>■ String 

merge = output o run o concat o map write 

Of course, this function also works for hnite lists, and can be adapted to act on 
more general lists than strings. 

4-3 Concurrent State 

In Haskell, the so-called 10 monad provides mutable state. Within the monad we 
can create, access, and update pieces of storage. The type of a storage that contains 
an object of type a is Var a. The functions we use to control these Vars, the non¬ 
proper morphisms of 10 , have the following types. 

newVar :: 10 (Var a) 
readVar :: Var a —> 10 a 
writeVar :: Var a —> a —> 10 () 

In the lifted version of this monad, the CIO monad, we can have several concurrent 
processes sharing pieces of state. In a concurrent world however, we often want 
more structure on shared state. Concurrent Haskell (Peyton Jones et al, 1996), an 
extension of Haskell with primitives for creating concurrent processes, recognised 
this. It introduces a new form of shared state: the MVar . 

Like a Var, an MVar can contain a value, but it may also be empty. An MVar 
becomes empty after a process has done a read operation on it. Processes reading 
an empty MVar will block, until a new value is put into the MVar. MVars are a 
powerful mechanism for creating higher level concurrent data abstractions. They 
can for example be used for synchronization and data sharing at the same time. 

It is possible to integrate MVars with our concurrency monad transformer, using 
the mutable state primitives we already have. First, we have to think of how to 
represent an MVar. An MVar can be in two different states; it can either be full 
(containing some value), or empty. 
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type MVar a = Var (Maybe a) 
data Maybe a = Just a | Nothing 

We use the datatype Maybe to indicate that there is Just a value in an MVar, or 
Nothing at all. 

Let us now define the operations that work on MVars. The function that creates 
an MVar lifts the creation of a Var, and puts Nothing in it. 

newMVar :: C 10 (MVar a) 
newMVar = lift ( do « f- newVar 

; writeVar v Nothing 
; return v ) 

We can use the same trick when writing to an MVar .§ 

writeMVar :: MVar a4a->C 10 () 
writeMVar v a = lift ( writeVar v (Just a) ) 

The hardest function to define is readMVar, since it has to deal with blocking. To 
avoid interference when reading an MVar, we perform an atomic action that pulls 
the value out of the Var and puts Nothing back. We introduce an auxilary function 
take Var, working on the unlifted 10 monad, that does this. 

takeVar :: MVar a —> 10 (Maybe a) 
takeVar v = do a m readVar v 

; writeVar v Nothing 
; return a m 

Once we have this function, the definition of a blocking readMVar is not hard 
anymore. We represent blocking by repeatedly trying to read the variable. We 
realise that this busy-wait implementation is very inefficient, and we indeed have 
used other methods as well (such as the one used in (Jones, M. et at, 1997)), but 
we present the easiest implementation here. 

readMVar :: MVar a4C 10 a 
readMVar v = do a m <- lift (takeVar v) 

; case a m of 

Nothing —>■ readMVar v 
Just a —>■ return a 

Note that readMVar itself is not an atomic action, so other processes can also read 
the MVar just after takeVar . Fortunately, at that point, the MVar is already blocked 
by the function takeVar. It is impossible for readMVar to be atomic, since other 
processes deserve a chance when it is blocking on an MVar. 

§ We are a bit sloppy here; the real semantics of MVars is slightly different (Peyton Jones 
et al, 1996). 
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For some examples of the use of MVars, we refer the reader to the paper about 
Concurrent Flaskell (Peyton Jones et al., 1996), where MVars are introduced. 


5 Discussion 

The work presented in this paper is an excellent example of the flexiblity of monads 
and monad transformers. The power of dealing with different types of computations 
in this way is very general, and should definitely be more widely used and supported 
by programming languages. We really had to push the Haskell type class mechanism 
to its limits in order to make this work. A slightly extended class mechanism would 
have been helpful (Peyton Jones et al., 1997). 

To show that this idea is more than just a toy, we have used this same setting 
to add concurrency to the graphical system TkGofer (Vullinghs et al., 1996). The 
system increased in expressive power, and its implementation in simplicity. It turns 
out to be a very useful extension to TkGofer. 

We have also experimented with lifting other well-known monads into this con¬ 
current setting. Lifted lists, for example, can be used to express the infinite merging 
problem more concisely. However, a problem with the type system forced us to fool 
it in order to make this work. Exception and environment monads (Wadler, 1995) 
do have the expected behaviour, though we are not able to lift all of the non-proper 
morphisms of these monads. This is because some of them need a computation as 
an argument, so that lifting becomes non-trivial. 

However, there are a few drawbacks. We have not implemented real concurrency. 
We simply allow interleaving of atomic actions, whose atomicity plays a vital role 
in the system. If one atomic action itself does not terminate, the concurrent com¬ 
putation of which it is a part of does not terminate either. We cannot change 
this, because we cannot step outside the language to interrupt the evaluation of an 
expression. 

The source code of the functions and classes mentioned in this paper is publi- 
cally available at http://www.cs.chalmers.se/~koen/Code/pearl.hs. It also contains 
another, more efficient but slightly bigger implementation of MVars. 
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